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Following established tradition, software engineering today is rooted in a conceptually centralized way of thinking. The 
primary SE artifact is a specification of a machine — a computational artifact — that would meet the (ehcited and) stated 
requirements. Therein lies a fundamental mismatch with (open) sociotechnical systems, which involve multiple autonomous 
social participants or principals who interact with each other to further their individual goals. No central machine governs 
the behaviors of the various principals. 

We introduce Interaction-Oriented Software Engineering (lOSE) as an approach expressly suited to the needs of open 
sociotechnical systems. In lOSE, specifying a system amounts to specifying the interactions among the principals as proto- 
cols. lOSE reinterprets the classical software engineering principles of modularity, abstraction, separation of concerns, and 
encapsulation in a manner that accords with the reaUties of sociotechnical systems. To highlight the novelty of lOSE, we 
show where well-known SE methodologies, especially those that explicitly aim to address either sociotechnical systems or 
the modeling of interactions among autonomous principals, fail to satisfy the lOSE principles. 

Categories and Subject Descriptors: H.1.0 [Information Systems]: Models and Principles; D.2.1 [Software Engineering]: 
Requirements/Specifications; 1.2.11 [Artificial Intelligence]: Distributed Artificial Intelligence — Muhiagent systems 

General Terms: Design, Theory 

Additional Key Words and Phrases: Protocols, Commitments, Actors, Agents, Autonomy, Distiibution, Goals 
1. INTRODUCTION 

We define a sociotechnical system as one involving interactions between autonomous social en- 
tities such as people and organizations mediated by technical components. By emphasizing the 
autonomous nature of social entities, our definition generalizes over, yet more precisely captures, 
the traditional connotation of the interaction between humans and societal infrastructure. Our defi- 
nition contrasts with one of the conventional uses of the term, which covers any interaction between 
people and computers. 

Researchers in software engineering (SE) picked up the theme of sociotechnical systems in two 
major directions: (1) how to model a sociotechnical system as a combination of social and soft- 
ware components, as in jBryl et al. 2009 |Yu 1997t lYu et al. 201 111 ; and (2) how to elicit, model. 



and manage the requirements of the social components so that suitable software components may 
be designed BBaxter and Sommerville 201 l||Goguen 1994t|Mylopoulos et al. 1992[ . Often, there is 
substantial overlap between the two directions, for example, as in i* II Yu 19971 . Baxter and Som- 
merville 1 20 11 1 conceptualize a sociotechnical system as one that actively pursues goals in an orga- 
nizational setting; that is, a sociotechnical system is one actor: a single locus of control. Therefore, 
we refer to such systems as being conceptually centralized. The centralized conception is shared by 
current SE approaches. 

For clarity, we reserve the term principal to refer to an autonomous social party who participates 
in a system at runtime and the term stakeholder to refer to one who originates some of the require- 
ments. In general, any principal would also be a stakeholder in the system (suitably abstracted via 
the notion of roles). 

We restrict our attention to systems whose membership and structure can change dynamically. 
Such open sociotechnical systems are properly viewed as societies of principals: we cannot build a 
"complete" system but can only specify how its members may interact, leaving as out of our scope 
the engineering of the members themselves. Thus whether the members comply with the specified 
interactions is crucial. Because of its emphasis on interaction, we term our approach interaction- 
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oriented software engineering or lOSE. We claim that lOSE is necessary and show that the central- 
ized conception is not applicable in sociotechnical systems. 

1.1. Example: Healthcare 

Common settings such as business services and social computing realize open sociotechnical sys- 
tems. Consider Schield et al.'s I12001II description of a healthcare system in the United States, in- 
cluding its key stakeholders and their (presumed) objectives. 

— US SOCIETY: the collective public, private, and personal interests of the United States citizens. 

— REGULATORY BODIES: pubHc and private that make and enforce policies. 

— MCO: managed care organizations (i.e., licensed insurance organizations), who offer and admin- 
ister managed care plans. 

— INSTITUTIONAL PROVIDERS: hospitals and laboratories. 

— CLINICAL OR PROFESSIONAL PROVIDERS: individual doctors and communities of practice. 

— EMPLOYERS: fully insured and self-funded organizations who offer managed care plans to their 
employees. 

— CONSUMERS: the enrollees of managed care plans. 

— MEDICAID OR MEDICARE BENEFICIARIES. 

Schield et al. find that the stakeholders' objectives often conflict. For example, payers must keep 
costs down whereas providers must maximize revenue; insurers want to shift risk to providers and 
consumers for matters of cost control whereas both providers and consumers want protection from 
potentially catastrophic costs. Consumers want shorter waiting periods for appointments with their 
physicians whereas physicians want to increase their panel of patients. Further, Schield et al. point 
out how one principal can, in pursuing its own objectives, compromise the objectives of others. For 
example, making a patient wait longer may compromise the patient's health, thereby increasing the 
cost of care and decreasing patient satisfaction. Regulatory bodies have the objective of making sure 
MCOs and providers play by the rules and ensuring that cost, quality, and access criteria are met but 
that conflicts with society's goals of lower-cost healthcare. 

Assume that the stakeholders for a healthcare system manage to resolve their differences and 
specify a system that meets their stated collective requirements. Now, individual principals such 
as specific MCOs, hospitals, physicians, employees, and consumers can join or leave the managed 
healthcare system of their own volition. The principals act according to their own private business 
policies, some of which may not have been envisaged by the stakeholders. For example, an MCO 
may have a private objective to acquire an independent call center 

Further, principals would generally employ their own internal information systems to support 
their interactions with other principals. For example, providers may set up appointment systems to 
handle appointment-related communications with consumers. Hospitals and MCOs may use com- 
plex information systems that help process payments from each other and the consumers. MCOs 
may employ complex actuarial and decision-support processes in handling claims. 

Recognizing and addressing conflicts among stakeholders requirements has been a longstand- 
ing area of research in software engineering. Once the conflicts are addressed, through whichever 
means, engineers would seek to model and realize a system that meets those requirements. This pa- 
per treats conflict analysis as out of scope and instead focuses on identifying modeling assumptions 
and criteria that capture sociotechnical systems more faithfully. 

1.2. Contributions and Organization 

This paper makes two main contributions. First, it shows via conceptual analysis why lOSE is (1) 
a novel paradigm and (2) well-suited for the software engineering of open sociotechnical systems. 
Our argument proceeds as follows. One, we show that the foundational models of traditional SE are 
conceptually centralized. This is because traditional SE concerns itself with the engineering of what 
is conceptually a single machine (Section |2l). Two, we present the conceptual model of a system 
in lOSE (Section [3j and discuss how it accommodates multiple perspectives. Three, based on the 
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characteristics of sociotechnical systems, namely, autonomy, accountability, and loose coupling, we 
formulate criteria that any SE approach for them should meet and show that whereas machine- 
orientation, and therefore traditional SE, fails the criteria, lOSE meets them (Section|4]l. 

The second contribution of this paper lies in reinterpreting the broad SE principles of modularity, 
encapsulation, abstraction, and the separation of concerns in accordance with the above criteria 
(Section |5]l. The reinterpretation provides the elements of a methodology for lOSE. Further, we 
discuss in detail well-known software methodologies that are motivated either by sociotechnical 
systems or the modeling of interactions among principals and show how they violate one or more 
of these principles (Section |6]l. Section [T] discusses additional literature that is relevant to lOSE. 
Section[8]concludes the paper with pointers to future directions. 

2. TRADITIONAL SOFTWARE ENGINEERING: MACHINES 

Figure[T](from Van Lamsweerde |2009 |) shows the traditional conceptual model for SE. The system 
as is represents the system with identified problems, inefficiencies, and limitations. The system to 
be, whose objectives are to avoid those deficiencies, is to be engineered. The idea is to understand 
the problem domain in order to come up with a set of services, constraints, and assumptions under 
which the stated objectives would be met. Some of these would be met by the software to be as part 
of the system to be; the rest would be assigned as responsibilities to components in the environment, 
nameb/, people, devices, and existing software. 




Even more generally, given a set of requirements, the essential idea is to come up with the spec- 
ification of a machine (equivalently, the software to be above) that along with reasonable domain 
assumptions satisfies the requirements of the stakeholders IZave and Jackson 199711 . The system as 
is is the system as it exists without the machine and helps us understand the environment in which 
the machine will be introduced. The system to be is what the system will be when the machine is 
introduced. If all goes well in the system to be, the stakeholders' requirements are satisfied. 

It is important to understand the nature of the machine. Figure |2] (from Ivan Lamsweerde 20091 
but based on | (Parnas and Madey 1 995 J ) illustrates an operational conceptualization of the machine- 
environment interface. Here, the software to be represents the machine. A machine is a controller 
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that maps inputs from its environment (by monitoring certain variables) to outputs or effects in the 
environment (by setting certain variables). In other words, it processes inputs to produce outputs. 
To its users (in the environment), a machine provides computational services (functionality). 

In its very conception, a machine corresponds to a single locus of control. Indeed, it is common 
in software engineering to talk of machines as acting in pursuit of goals Ivan Lamsweerde 200911 . 
Traditional SE is machine-oriented — it concerns itself with the specification of a machine (even if 
implemented via distributed components) that would meet stakeholder requirements. Thus tradi- 
tional SE reflects a conceptually centralized perspective, namely, of the stakeholders, considered 
collectively. 



Monitored Input 

variables Input Devices data 

f (Sensors) ^ 



Environment Software to be J 



Output Devices 



Controlled (Actuators) Output 

variables data 

Fig. 2: The machine-environment interface Hvan Lamsweerde 20091 . 



The above account of machine-orientation, taken from leading writings on SE, is agnostic to par- 
ticular software methodologies. Machine-orientation manifests itself in specific modeling notations 
and methodologies, some of which have been highly influential in SE. Many existing requirements- 
based approaches, although differing in their details, instantiate the same concepts at their core: ma- 
chine, environment, system as is, and system to be. Tropos (Bresciani et al. 2004 1 and i* II Yu 19971 
refer to a model of the system as is and the system to be as the early and late requirements mod- 
els, respectively. In their terminology, the environment is a set of actors; the machine itself is the 
system actor. For example, Tropos would create a system actor for an entire healthcare system. 
This actor would capture (a consistent subset of) the goals of all stakeholders, thereby functioning 
as a logically centralized machine. Following KAOS [Dardenne et al. 1993 1, one would create a 
set of agents with designer-assigned individual goals. However, the set of agents is conceptually a 
single machine because there is a single locus of design. This follows from the fact that goals are 
assigned to agents and, therefore, at a high-level the agents have akeady been specified. Indeed, 
referring specifically to KAOS (and to Feather's work 1 1987|, which provides the conceptual basis 
for KAOS), Zave and Jackson |1997| observe that even though KAOS supports multiple agents, it 
is only a refinement of their more basic single-machine framework. 

Let us apply the above conceptual model of systems to the healthcare scenario. Imagine that a 
healthcare machine were built to a specified set of stakeholder requirements. The machine would 
control various medical devices and other equipment. Users such as consumers, providers, MCOs, 
and so via on would interface with the machine via a Web interface. Consider the example of 
scheduling an appointment with a physician. The physician would have configured his or her pref- 
erences in the machine: his or her daily schedule, how long a time period to allot each patient, 
and so on. Those are the physician's inputs to the machine, which the machine uses in scheduling 
patient appointments. The patient's interface would display the available slots and enable him or 
her to choose from among those slots. The machine records each selection, and produces as out- 
put a confirmation of the appointment, perhaps also by email. Further, the machine grays out the 
slot for future scheduling. The machine additionally supports the processing of claims and payments 
among hospitals and insurers. The machine would encode the insurance company's process of queu- 
ing claims above $10,000 separately for detailed examination. The insurance company through its 
interface can obtain the claims from the appropriate queues. The machine would implement the 
appropriate access control so that users can access the appropriate functionality. 
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Traditional SE, in spite of its conceptually centralized perspective, may be applied to yield a 
physically distributed machine. Web applications suggest physical distribution and applying KAOS 
would result in a physically distributed set of agents. In general, techniques from software architec- 
ture may be applied to internally decompose a machine into distributed components. Rapanotti et al. 
||2004J employ such an approach in the decomposition of machines in the problem frames approach. 

3. lOSE CONCEPTS 

We define a protocol of a sociotechnical system as a specification of how interactions among 
its roles would proceed. In business settings, the protocol can take the form of a business 
contract that principals would enter into upon adopting different roles. For example, in Texas, 
if MedCo wishes to play the role of MCO, it must enter into a Uniform Managed Care 
contract with the state health commission (which alone plays the REGULATORY BODY role) 
IITexas Health and Human Services Commission 20121 . 

At any point during the interaction, the set of social expectations represents the social state of 
the system. A protocol serves three purposes. One, it makes public the social expectations of the 
participants while giving them the flexibility to follow their individual objectives. For example, 
public funding agencies may expect that MCOs, upon notification, refund payments made in error 
within 30 days. Two, it identifies which participant is accountable to which participant for what 
expectation. For instance, if MedCo, who plays MCO, does not refund an erroneous payment in 
time, the funding agency may hold MedCo accountable. Three, it frees participants to implement 
their information systems as they please as long as they satisfy the given protocol. For example, 
MedCo might employ any representation it chooses and may apply its policies in deciding whether 
to provide a refund early or late within the 30-day window. 
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Fig. 3: The lOSE approach schematically. 



Accordingly, the objective of lOSE is to specify a sociotechnical system as a protocol that de- 
fines two or more roles. Figure [3] describes how lOSE applies. For the sociotechnical system to be 
instantiated, principals adopt roles in the protocol. Each principal continues to interact with its envi- 
ronment even after it joins the system. The principals communicate with each other within the scope 
of the system, which means that they are subject to the meanings defined in the protocol that spec- 
ifies the system. In engineering terms, the main artifact produced by lOSE is the protocol which, 
through its roles, itself serves as a requirement for the principals who would adopt those roles. 

Whereas traditional SE seeks to specify a machine, lOSE seeks to specify a protocol. Whereas a 
machine captures a single locus of control, lOSE naturally supports multiple perspectives as roles in 
a protocol. In lOSE, each principal, who adopts one or more roles, is a locus of control — a reasoner 
and a sender and receiver of communications. 
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3.1. Commitment Protocols as an lOSE Approach 

We introduce commitment protocols I jYolum and Sing h 2002] as an example lOSE approach. A 
(social) commitment captures an elementary business relationship between a debtor and a creditor 
I Singh 1999) . Specifically, the commitment C(a;, y, r, u) says that the debtor x commits to the cred- 
itor y that if the antecedent r comes to hold, then it will bring the consequent u. The elementary 
operations on commitments are Create, Release, Cancel, Delegate, and Assign. The social nature of 
commitments owes to the fact that they progress due to interactions among principals, not due to the 
internal reasoning of any principal. Commitment protocols exploit this connection by specifying the 
meanings of messages in terms of how they affect commitments, thus enabling principals to interact 
flexibly. Other abstractions could potentially be used in addition to commitments but, for simplicity, 
we confine the present discussion to commitments. 

Table I] shows a partial appointment scheduling protocol. The protocol involves two roles, PHY 
(for physician) and PAT (for patient). Assume that via the enactment of some other protocol, (any 
physician playing) PHY is committed to (any patient playing) PAT to provide the latter with a list of 
available appointment slots upon the latter's request for appointment (this commitment, for instance, 
could be set up when a patient registers with a physician for the first time). We represent this com- 
mitment as C(PHY, PAT, requestAppointment(PAT, PHY), availableSlots(PHY, PAT, s)). The avail- 
ableSlots message from PHY to PAT conveys the list of available slots to the PAT: it means that PHY 
commits to PAT that if PAT commits to show up for one of those slots, then PHY will commit to 
showing up for that slot as well. The select message from PAT to PHY commits PAT to a selected 
slot. The confirmSlot message from PHY to PAT for a particular slot commits PHY to the slot. A 
complete and effective meeting scheduling protocol would additionally include messages that deal 
with meeting cancellation and rescheduling. 



Table I: A partial appointment scheduling protocol. 



Message Meaning 

avai/aWeS]ots(PHY, pat, s) C(phy, pat, 3s e s : C(pat, phy, T, showUp(PAT, s)), 

C(PHY, PAT, T, showUp(PHY, s))) 
selectSlot(?AT, PHY, s) C(pat, phy, T, showUp(PAT, s)) 

conSnnSIot(mY , PAT, s) C(PHY, PAT, T, showUp(PHY, s)) 



Table II: Commitments involved in the appointment scheduling protocol. 



Label 


Commitment 




CO 


C{Alessia, Bianca, requestAppointment (Bianca, Alessia), availableSlots(yl(essia 


, Bianca, s)) 


Cl 


C{Alessia, Bianca, T, availableSlots(yl(essia, Bianca, s)) 




C2 


C{Alessia, Bianca, 3s G {1400, 1600} : C{Bianca, Alessia, T ,shovjUp{Bianca, ^ 


0), 




C{Alessia, Bianca, T, showUp{Alessia, s))) 




C3 


C{Alessia, Bianca, T, C{Alessia, Bianca, T, showUp{Alessia, 1400))) 




C4 


C{Bianca, Alessia, T, shovjUp{Bianca , 1400)) 




C5 


C{Alessia, Bianca, T ,shovjUp{Alessia, 1400)) 





Figure|4]depicts the progression of social state according to the meanings in Table|T]and using the 
commitments introduced in Tablellll Alessia plays PHY and Bianca plays PAT. Upon Bianca sending 
the requestAppointment message to Alessia, the antecedent of cq is satisfied. This makes Alessia 
unconditionally committed to sending her the available slots (ci). When Alessia sends the list of 
available slots (at 1400 and 1600 hours), she discharges ci and creates C2. Bianca communicates her 
selection of 1400, which makes Alessia unconditionally committed to confirming it; in other words, 
Bianca creates C4, which creates C3 (the unconditional version of C2). Finally, Alessia confirms the 
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selected slot, thus creating C5 and discharging C3. In the final state of Figure |4] both Alessia and 
Bianca are committed to each other for showing up at the selected time. 




Fig. 4: Progression of the social state during an enactment of the appointment scheduling protocol. 



Protocols for handling claims between providers and MCO would be more complex than those 
for appointment scheduling. Desai et al. 020101 specify protocols for automobile insurance and 
show how to compose protocols. We focus on appointment scheduling because (1) it illustrates the 
essential concepts of lOSE, and (2) it bears similarity to meeting scheduling, an application that has 
been studied extensively in the literature, and which we discuss in detail in Section |6] 

4. EVALUATING MACHINE-ORIENTATION AND lOSE 

Figure|5]describes three takes on a sociotechnical system. Figure |5a] shows the most traditional set- 
ting, which even predates IT. Here, one can imagine a sociotechnical system as realized by two or 
more principals, each with its own ledgers, and interacting via the postal service or foot messen- 
ger. The principals are autonomous. The same situation holds in the case of digital communication, 
where we can think of the messaging system as providing the necessary message delivery function- 
ality. In this case too, the messages the principals send and receive are opaque to the communication 
network. In either case, there is no computational support for the social state. Indeed, there is no 
computational support for anything beyond message transport and, possibly operational constraints 
such as message ordering. Each principal maintains its expectations and commitments in its ledgers 
and acts according to its local policies. For example, a physician may send a request to a laboratory 
to find a patient's cholesterol and the laboratory may send back the results along with an invoice. 

Figure |5b] shows a more sophisticated, but traditional, approach wherein a machine mediates all 
interactions among the principals. The machine offers an API to the principals through which they 
can request changes in the social state. Such conceptually centralized machines are not common 
for healthcare today, so we use eBay as an example and then return to healthcare. The auctioneer 
eBay offers a machine for conducting auctions that provides an API (requiring little more than a 
web browser) through which sellers can list items for sale and buyers can bid for listed items. The 
machine determines the social state: whether something is on sale, its reserve price, the time an 
auction closes, whether a bid is legitimate, the winning bid, and so on. The principals can represent 
their local view in their ledgers but what matters is the eBay machine's view. The machine happens 
to usually respect the requests of buyers and sellers but it does not need to. 
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Fig. 5: A historical perspective on the placement and computation of social state. 



Returning to the healthcare machine of Section|2l the patient may attempt to schedule an appoint- 
ment with the physician, but the machine determines whether the appointment holds, i.e., whether 
the patient and physician are each committed to showing up at the appointed time. The patient and 
the physician may maintain their local views of the social state but what the machine maintains is 
definitive. The same situation arises between the hospital and MedCo regarding their payments. In 
this setting, the only way the parties can interoperate is if they maintain their local views tightly 
synchronized with the central machine. 

In contrast, Figure|5c]shows how the principals enact a protocol with one another The enactment 
takes advantage of infrastructure such as for communication. However, the social state is determined 
not by the infrastructure but through the enactment of the protocol. That is, the protocol specifies 
how the social state progresses. Here too the principals can maintain their individual ledgers but 
what the protocol specifies is definitive. The important challenge of formalizing protocols to ensure 
that the local views remain sufficiently consistent with the protocol-specified "public" state without 
synchronization is out of our present scope. Chopra and Singh [2009 1 present a relevant approach. 



4.1. Criteria for Modeling Sociotechnical Systems 

Let us use the healthcare example of Section 11. 11 to motivate the key criteria that any software 
engineering methodology for sociotechnical systems must support. 

Accommodate autonomy The autonomy of a principal (a human, organization, or other social 
entity) means that it is an independent locus of control with its own goals and policies, which reflect 
its business motivations and are normally private. Thus even as a participant in a system, each 
principal is free in principle to act in pursuit of its own goals, without any consideration of others. 
For example, a hospital may decide not to entertain patients with a particular insurance provider, or 
physicians may increase the panel of patients they treat at the expense of reducing availability. 

Figure |5a] is compatible with autonomy only to the extent that it does not model social state. 
Figure |5b] violates autonomy because the machine not only determines the definitive social state 
but also controls transitions on it. The principals have no direct relationship with each other. For 
example, a bid may be declined and a seller may not be able to change his mind and accept a bid 
lower than the reserve price. 

Contrast the above with protocols. A protocol is not a computationally active entity and cannot 
provide a service. A protocol simply specifies the correctness criteria for interaction among the 
participants. Figure|5c]expresses a protocol that specifies the appropriate social relationships among 
potential principals, capturing their legitimate expectations of each other Further, principals would 
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enter into these relationships of their own volition; no relationship is forced upon a principal, not 
even to ensure compliance. 

Support accountability Accountability is the flip side of autonomy. A participant is free to act 
as it pleases; however, it is accountable to those that have legitimate social expectations of it. For 
example, a laboratory may legitimately expect that the MCO transfer funds for services provided 
within a certain time after submission of claims. This means that the MCO is accountable to the 
laboratory for transferring funds in time; if it does not, it violates the laboratory's expectation. 

Figure |5a| provides no support for accountability because it does not represent the social state. 
Figure |5b] holds each principal accountable to the central authority and, if it permits, to the other 
principals. For example, a buyer is accountable to eBay to pay in time. But if she persuades eBay to 
grant her an extension, the seller has no recourse within the eBay system. Figure|5c]bases account- 
ability on a protocol and thus each principal is accountable to any other principal in whom it has 
created a legitimate expectation. In particular, through the protocol, each principal ought to be able 
to judge the compliance with its expectations of each principal with whom it interacts. 

Accommodate loose coupling Loose coupling captures the idea that each principal is an indepen- 
dent locus of design. It has full control over the design of its own information systems but no control 
over the design of other principals' information systems. For example, a hospital may store infor- 
mation about a surgeon's willingness to work the night shift whereas the insurance company may 
capture the total charges for procedures led by that surgeon. And, hospitals in different jurisdictions 
may capture different patient monitoring data during a surgery. 

Figure |5a] is compatible with loose coupling insofar as it elides the treatment of social state. In 
practice, it forces an ad hoc design of the interaction (e.g., message formats). Because the message 
meanings are hidden, the principals who adapt their information systems risk failing interoperabil- 
ity. Figure |5b] requires that the principals adopt the same representation of the social state as the 
machine. The meanings of the messages sent over the API could be explicit but they usually are 
hardcoded in the machine, and sometimes in the principals' information systems, if any. This pro- 
duces a tighter coupling than desirable between the principals and the machine (both considered 
as endpoints): when the machine changes, the principals must potentially change their own behav- 
iors and any information systems that support them accordingly. By contrast. Figure |5c] employs a 
protocol with explicit meanings (not hardcoded in any principals' information system) for the inter- 
actions. The lOSE approach, in effect, makes public the extent of the coupling. The principals may 
adapt their information systems without consideration of others as long as they follow the protocol. 

5. PRINCIPLES OF lOSE 

We introduce the core principles of lOSE. Specifically, we contrast how the key principles of SE: 
modularity and encapsulation IParn as 1 9721 . separation of concerns [Dijkstra 1982], and abstraction 
are manifested in current modeling approaches with how they are manifested in lOSE. We find that 
although the intuitions behind the principles hold, the technical details are completely different and, 
in many cases, antithetical to what we encounter in conventional SE. 

5.1. Accountability Modularity: Embedding in the Social World 

Modularity refers to the functional, most commonly hierarchical, decomposition of systems 
BParnas 1 97 2 1. The benefit of appropriately modularizing systems is composability. In the extreme, 
modules from different vendors may be composed as needed. 

As Figure |2] shows, the first-level application of modularity in SE is the decomposition of the 
system into the environment and the machine. Rapanotti et al. |2004| apply architectural patterns 
to decompose a problem frame into its constituent problem frames. KAOS, i*, and Tropos, being 
agent-oriented, support finer grained units of modularity. The agents therein may have responsibili- 
ties or provide services, as captured by the dependencies among them. 



A:10 



Chopra and Singh 



In lOSE, a principal as an autonomous social entity is the natural unit of modularity. With auton- 
omy comes accountability, as motivated by Mamdani and Pitt |2000 |. Without the ability to check 
compliance, though, accountability would be meaningless. 

Example. Although Bianca is free to not show for the appointment once she commits to a slot, 
she is accountable for her commitment. 

Benefit. Promotes autonomy by not unduly restricting a principal's course of action. Promotes 
accountability by providing a basis for ensuring correctness: a principal who does not comply may 
face sanctions from principals to whom it is accountable for the given expectation. 

Each principal autonomously becomes the debtor of any commitments [Sin gh 1999[ . That is, the 
debtor must have initiated an interaction (sent a message) that leads to it being committed. In some 
cases, the message could itself create the commitment. In other cases, the debtor may have created 
some commitment (as debtor) whereby actions by other parties could lead to the creation of the 
given commitment. Because commitments are created ultimately due to the communications of the 
debtor, the debtor is accountable for them. Demands placed on a principal other than as the debtor 
of a commitment have no bearing on compliance or enforcement. 

5.2. Abstraction: Emphasis on Social l\/leaning 

Abstraction refers to the level of the concepts used in a specification. The ideal abstraction is suffi- 
ciently high-level to hide details and reduce complexity, yet sufficiently low-level to support drawing 
the necessary conclusions. Tropos and i* offer high-level abstractions such as goals, capabilities, 
and goal dependencies. Sommerville et al. |20091 apply high-level notions of responsibility and 
delegation to requirements modeling. Using high-level abstractions places requirements away from 
low-level notions such as tasks, plans, and state machines. In contrast, lOSE emphasizes abstrac- 
tions that capture the meaning of an interaction. 

Explicit Social Meaning Make all social expectations explicit in the system specification. The 
meanings of individual communications must be explicitly formalized in terms of what they count 
as in the society being designed. In general, the meaning involves the creation or other manipulation 
of the commitments among the parties involved. 

Example. Table U specifies the message meanings in an appointment scheduling protocol. 

Benefit. Explicit social meaning promotes loose coupling. As Figure |4] illustrates, the meaning 
captures how the principals' social state progresses. The true social state progresses even if we have 
no computational representation of it. But lacking an explicit meaning, each principal could interpret 
messages in incompatible ways. For example, in the healthcare setting, a laboratory may interpret 
the messages with the claim information as leading to an unconditional commitment from the MCO 
to honor the claim. The MCO, however, may interpret the commitment as being conditional on the 
claim being valid. Such misalignments could have serious repercussions for the principals (e.g., 
in producing their balance sheets) and may lead to legal disputes. If the principals negotiate the 
meanings of the messages and hard-code them in their information systems, they would produce 
hidden couplings among themselves: changes in how one principal handles messages would need 
to be propagated to the others. 

Additionally, explicit social meaning promotes accountability because if the meanings are public, 
then principals can potentially check the compliance of themselves and others. 

Solely Social Meaning A system specification must specify only the possible communications and 
their meanings and nothing else. Further, the meaning must be expressed in terms of social abstrac- 
tions such as commitments. Specifications of any operational details that have significance at the 
social level (e.g., a convention to pay first), must be captured via social abstractions (e.g., commit- 
ments). Specifications that capture ordering and occurrence constraints separately from the meaning 
violate this principle. For example, one could specify in the appointment scheduling protocol that 
availableSlots follow requestAppointment. But here no one is accountable for the constraint: is the 
physician at fault for not delaying sending availableSlots or is the patient at fault for not sending 
requestAppointment! Instead, if this constraint is necessary as a social requirement, one or more of 
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the principals should commit to enforcing it, e.g., adopting Marengo et al.'s II2011I approach and 
placing temporal constraints in commitments. 

Further, specifying the technical infrastructure does not capture a sociotechnical system. We 
might either model the social actor who provides the infrastructure and engage it via commitments 
or omit such technical constraints altogether since they apply at a lower level of abstraction. 

Example. The above ordering constraint can be expressed | |Marengo et al. 20TT) as 
C(PHY, PAT, T, requestAppointment • availableSlots) where the dot ('•') means occurs before. 

Benefit. Promotes autonomy and accountability. No central controller enforces constraints in a 
sociotechnical system. Every constraint logically ought to be some principal's responsibility. Ex- 
pressing a constraint as a hard constraint to be enforced magically by the environment either under- 
specifies the functioning of the system or (in most current thinking) postulates a central entity that 
is the sole autonomous principal and can impose its will upon all the other participants. 

5.3. Separation of Social and Technical Concerns 

Separation of concerns refers to the treatment of each aspect of a problem independently of yet in 
relation to others. It refers to the sorting out of the different threads from what would otherwise be 
a tangled mess. Often, the invocation of this principle is implicit. For example, Zave and Jackson's 
identification of domain assumptions, machine requirements, and user requirements as the separate 
but essential categories for RE is at its heart an application of this principle. Dardenne et al. M1993I 
and Yu 1 1997] express early requirements in the form of goal models, thus separating the exploration 
of the problem space from the solution space. Mylopoulos et al. [1992 1 separate nonfunctional from 
functional requirements. Finkelstein et al. 1 1992 1 separate concerns explicitly based on stakeholders, 
acknowledging the fact that, in general, each stakeholder has different concerns and may employ 
different representations for expressing them. 

For sociotechnical systems, we must separate social and technical considerations. Principals such 
as people and organizations must be distinguished from technical entities such as resources, legacy 
systems, software components, devices, communication infrastructure, and other technical objects 
in the environment. This is because social relationships are meaningful only among principals. A 
principal may only bear a control relationship (e.g., ownership, invocation, or access) toward a tech- 
nical entity as may one such entity toward another Only principals are autonomous and accountable: 
a patient cannot sue an operating table but can sue a surgeon or a hospital. 

Example. As Figure |4] shows, Alessia and Bianca maintain a social relationship. However, each 
of them maintains and controls an information system, which is not socially visible. 

Benefit. Separating the social and technical entities makes clear the kinds of relationships that 
would make sense among them. Promotes accountability by making clear only principals are ac- 
countable to each other in the social sense. Enables engineers of sociotechnical systems to focus 
solely on the social aspects. 

5.4. Encapsulation: No Principal Internals 

Encapsulation refers to the principle that a module reveal no more information than is necessary to 
effectively use it, in particular, that it reveal no implementation details. 

Figure|2]highlights the interface between the machine and the environment but does not bind the 
machine to any particular internal implementation. Zave and Jackson [1997| characterize RE as the 
process by which you arrive at the machine-environment interface; anything more would amount to 
prematurely determining an implementation. In i* and Tropos, dependencies among actors corre- 
spond to their interfaces. 

The idea of encapsulation, namely, to avoid examining the internals of a component, remains 
appropriate in lOSE. A direct consequence of this principle is that a sociotechnical system cannot 
be specified in terms of mental abstractions such as beliefs, goals, intentions, and so on — neither 
of its stakeholders nor of the principals who may participate in it. In particular, roles cannot be 
specified in terms of mental abstractions. In lOSE, each role in a protocol refers only to the social 
commitments resulting from the communications that a principal adopting it would be involved in. 



A:12 



Chopra and Singh 



Example. Neither the PHY role nor the PAT role has goal of scheduling appointment; neither do 
they have a shared (joint) goal to schedule appointments. 

Benefit. Promotes loose coupling by hiding details not relevant to the interaction. Also promotes 
accountability: a key reason we cannot use mental concepts to specify a sociotechnical system is that 
they make determining compliance impossible ^Singh 1998J . As mentioned earlier, accountability 
is meaningless if we cannot check compliance. 

5.5. Summary of Principles 

Table Ulllpresents the principles and their benefits at a glance. 



Table III: lOSE principles for sociotechnical system specification and their benefits. 



Principle 



Interpretation 



Benefits Promoted 



Accountability Principals are tiie basic units of autonomy and, tiierefore, modularity, 

modularity Principals are accountable for their communications and the resulting 

social expectations, e.g., commitments. 

Explicit social The social meaning of communication should be made explicit in sys- 

meaning tem specifications. 

Solely social Specify only communications and their social meaning, not control flow 

meaning or other kinds of low-level constraints 

Separating social Social relationships hold among principals, not among principals and 

from technical technical components and neither among technical components 

No principal in- System specifications should not refer to the internals of principals 
ternals 



Autonomy and ac- 
countability 

Accountability and 
loose couphng. 
Autonomy and ac- 
countability. 
Modeling perspicuity 
and accountabihty. 
Accountability and 
loose coupling. 



6. COMPARING lOSE WITH PROMINENT SE METHODOLOGIES 

We now evaluate lOSE with some prominent approaches from SE. We choose these either because 
(1) they are representative of broad classes of approaches for modeling sociotechnical systems (i*, 
Tropos, KAOS), or (2) they give emphasis to interaction and protocols (Gaia and Choreographies). 

6.1. i* and Tropos 

Lacking a treatment of healthcare in i* and Tropos approaches, we study Yu's treatment of meeting 
scheduling in i* MYu 19971 , which is similar in spirit to the appointment scheduling protocol dis- 
cussed earlier. Despite its simplicity, meeting scheduling provides sufficient subtlety to demonstrate 
various modeling approaches Ivan Lamsweerde et al. 19951 and is extensively used in the literature. 
The main requirement in this scenario is to automate and make efficient some aspects of meeting 
scheduling so that the meeting initiator's burden is reduced. 

Figure |6] shows the system to be for a meeting scheduling system in the i* notation. The circles 
represent the actors in the system: MEETING INITIATOR (Ml), MEETING PARTICIPANT (MP), and 
MEETING SCHEDULER (MS). The directed links between the actors represent dependencies. For 
example, MI depends on MP for achieving the goal that the participant attend the meeting (Attends 
Meeting). In the i* terminology, Figure|6]is a strategic dependency (SD) diagram. 

According to Yu, in early requirements engineering, i* helps come up with an initial set of re- 
quirements. Specifically, i* helps identify the goals of the various stakeholders and their dependen- 
cies in achieving those goals. A new system actor is introduced unto which some of these goals are 
delegated. The system actor represents the machine to be designed to meet stakeholder goals. This 
goal-modeling phase helps refine the system actor's goals and its dependencies with the other actors. 
In Figure |6] the meeting scheduler MS is the system actor and is responsible for many tasks that MI 
was responsible for in the system as is (not shown), such as obtaining availability information from 
participants and choosing a date that suits all participants. 

Tropos is an agent-oriented software engineering (AOSE) methodology that builds on the i* meta- 
model IBresciani et al. 20041 . Tropos follows i*'s goal modeling phase with an architectural phase 



Interaction-Oriented Software Engineering 



A:13 




Fig. 6: The meeting scheduling system to be II Yu 1 99711 . The machine is the Meeting Scheduler. 

that maps the system actor to new actors that are interconnected through appropriate data and control 
dependencies. The detailed design phase models each of these actors as one or more belief-desire- 
intention agents. The implementation phase realizes the agents, thereby completely implementing 
the system actor. Both i* and Tropos would create a system actor for an entire healthcare system. 
This actor would capture (a consistent subset of) the goals of all stakeholders, thereby functioning 
as a logically centralized machine. The comments below apply equally to i* and Tropos. 

— Accountability Modularity: Violated. There is no discrete principal behind the system actor 
and it is not meaningful to talk of its accountability. For example, MS, the system actor in 
Figure |6] is not accountable to the stakeholders. In general, dependencies in i* do not support 
accountability — just because an actor depends on another for a goal does not make the latter 
accountable for it. For example. Figure |6] shows that the MI depends on the MP for attending the 
meeting; however it does not automatically follow (without reasoning about communication and 
the resulting commitments, as in lOSE) that the MP is accountable for showing up. 

— Explicit Social Meaning: Partially fulfilled. The purpose behind the notion of dependencies in i* 
was to capture interactor relations in terms of high-level abstractions. However, i* dependencies 
refer to actors' mental states, and are not social, as further explained under encapsulation below. 

— Solely Social Meaning: Partially fulfilled. Dependencies are the only interactor abstraction. 
However, as we mentioned above, i* dependencies are not social abstractions. 

— Separating Social from Technical: Partially fulfilled, i* treats social and technical actors alike 
with the same kinds of dependencies between any pair of actors. For example, MS is a technical 
actor whereas MP and MI are stakeholders but MS's dependencies with MI and MP are of the same 
nature as those between MI and MP. However, to its credit, in the early requirements modeling 
phase, all the actors are stakeholders and only in the later phases (starting from late requirements 
modeling) are technical actors introduced. 

— No Principal Internals: Violated. An i* goal dependency between two actors x and y for some 
goal p means that x has a goal p, and y is able to achieve p and in addition intends to delivery. For 
example, as Figure |6] shows, MI depends on MS for its goal IVIeeting Scheduled. This dependency 
means that (1) MI has a goal to have the meeting; (2) MS is able to schedule the meeting; and (3) 
MS intends to schedule the meeting. In other words, a goal dependency expresses a shared goal, 
indicating joint intentionality, among the actors. (Soft goal, task, and resource dependencies 
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are interpreted analogously.) Thus the connection expressed between actors is rooted in their 
internals. Indeed, Yu states this: "The Strategic Dependency model aims to present a picture of 
agents by explicitly modeling only their external intentional relationships with each other The 
semantics of these external relationships, however, are characterized in terms of some presumed 
internal intentional features of the agent" II Yu 19951 p. 26, emphasis added]. 

In summary, the good points about i* and Tropos are that they model stakeholders and stakeholder 
relations explicitly as actors and dependencies. Their shortcomings include the machine-orientation 
underlying the notion of system actor; mentalist dependencies; and violation of encapsulation. That 
is, i* and Tropos can help design a machine in a cooperative setting, where autonomy is not a 
consideration, but do not adequately address the engineering of a sociotechnical system. 

6.2. KAOS 

Dardenne et al.'s II1993I KAOS resembles Tropos in its goal-orientation. KAOS first elicits stake- 
holders goals and represents them as AND-OR graphs. Next, it selects a particular variant of the 
graph as the basis for further engineering. Domain analysis reveals the possible sets of agents in 
the system to be along with their capabilities. KAOS's strength lies in the methodological details of 
deriving operational constraints from goals and assigning them to particular agents as responsibili- 
ties depending on their capabilities. For uniformity, we consider examples from van Lamsweerde et 
al.'s 1 19951 study of the meeting scheduler. 

The notion of agents in KAOS is fundamentally different from that of principals in lOSE. Agents 
in KAOS may be social (human) or technical, e.g., devices and software programs. Further, an 
agent is considered a performer of actions, which are themselves defined in terms of input, output, 
precondition, and postcondition. For example, van Lamsweerde et al. specify a scheduler agent that 
has the capability to perform the action DetermineSchedule, whose preconditions are that the meeting 
be requested but not scheduled and whose postconditions are (1) if the meeting is feasible, it is 
scheduled and (2) if it is not, the scheduling attempt fails. Other agents in van Lamsweerde et al.'s 
meeting scheduling system are participant and initiator, which are analogously specified. 

In KAOS, a system specification captures adequately refined goals (operational in nature) and 
their assignment to agents with the requisite capabilities. For example, the goal of notifying par- 
ticipants is assignable either to the initiator or scheduler because they are both capable of notifying 
participants; the goal of maintaining an up-to-date agenda that the scheduler could consult is the 
responsibility of every participant; and so on. The idea is that if the agents are appropriately specified 
and the goals are appropriately assigned, then overall system goals would be met. 

KAOS specifications capture neither communications among the agents nor explicit relation- 
ships among them. Instead KAOS conceptualized agents as monitoring and setting the appropriate 
system-level (meaning global) variables and predicates. 

KAOS would model the healthcare system via multiple agents but assign the goals of each agent, 
thereby creating a conceptually centralized machine. The contrast with lOSE principles is stark: 

— Accountability Modularity: Violated. KAOS's notion of composite system is exactly 
that of Figure |2] the two components are the automated system and the environment 
Mvan Lamsweerde et al. 19951 . The users are considered part of the environment. The automated 
system consists of software agents. Thus KAOS supports the specification of a distributed ma- 
chine (for example, above, we discussed the KAOS specification of agents for the meeting sched- 
uler system). The automated system represents the realization of the stakeholder requirements; 
hence it is meaningless to talk its accountability to anyone. We note here that the notion of re- 
sponsibility in KAOS in not a social one: a responsibility is simply an operational constraint that 
is assigned (and therefore, designed) into an agent. 

— Explicit Social Meaning: Violated. KAOS does not model communication nor employ any 
communication-related social abstractions. Further, unlike Tropos, it does not have abstractions 
to capture any interagent relations. All interaction between agents is captured only indirectly — 
through the setting of the appropriate variables and predicates in the environment. 
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— Solely Social Meaning: Violated. Since KAOS does not support social meaning. 

— Separating Social from Technical: Violated. KAOS models a sociotechnical system in a purely 
technical way. Neither stakeholders nor principals are accommodated in the system model. In 
fact, KAOS does not even model the goals as being of particular stakeholders: there is just one 
goal tree, which is progressively refined until the leafs can be assigned to agents. The names 
of the agents in the meeting scheduling system (participant, and so on) may suggest that KAOS 
accommodates principals. However, that would be misleading: agent specifications together with 
goal assignments are essentially abstract programs. The entire automated system is a collection 
of programs interacting via variables. 

— No Principal Internals: Violated. The system is ultimately a collection of agents whose assigned 
responsibilities determine their implementations. Since the system's correct functioning depends 
on the goals assigned to its member agents, KAOS breaks encapsulation. 

Like Tropos, KAOS applies in designing a technical system in a cooperative setting, but its 
machine-orientation precludes engineering an open sociotechnical system. 

6.3. Gaia 

Zambonelli et al.'s 020031 Gaia is one of the earliest AOSE methodologies. Later AOSE method- 
ologies bear many conceptual similarities with Gaia. Hence, it deserves an in-depth discussion. 

Gaia takes an organization-based approach in which agents may adopt roles. Zambonelli et al. 
consider a conference management system in which agents may adopt the appropriate roles (such 
as REVIEWER, PC MEMBER, AUTHOR, and SO on). A role defines the permissions and responsi- 
bilities of a prospective agent. Permissions describe what an agent could do with resources in the 
environment. Responsibilities are algebraic expressions over the protocols and internal activities that 
an agent must perform. For REVIEWER, the permissions are reads Papers and ctiange ReviewForms 
and the responsibilities are first ReceivePaper (a protocol), second ReviewPaper (an internal activity), 
and third SendReview (a protocol). Below we discuss Gaia with respect to the lOSE principles. 

— Accountability Modularity: Violated. In Gaia, technical components such as mail clients and ac- 
tive databases are agents. It is meaningless to talk about their accountability. Even if the agents 
represented only stakeholders, Gaia says nothing about to whom they are accountable. For ex- 
ample, if a REVIEWER may not send a review form, would it be responsible to the overseeing PC 
MEMBER? Gaia says nothing about that. 

Zambonelli et al. conceptualize the multiagent system as an organization that "can exploit, con- 
trol or consume when it is working towards the achievement of the organizational goal" (p. 328). 
Further, Gaia specifies organizational rules "that the organization should respect and enforce in 
its global behavior" (p. 335). Both these points seem to hint toward a conceptually central entity 
in the system. Although Gaia never explicitly mentions it, perhaps all agents that adopt roles 
are accountable only to this central entity. However, this resembles a conceptually centralized 
perspective and makes the system conception in Gaia similar to the one in Figure l5bl 

— Explicit Social Meaning: Partially fulfilled. Whereas Gaia supports specifying interaction 
among roles, it does not specify the meaning of the communications itself. Gaia has the no- 
tions of permissions and responsibilities at the role level. The intent behind these notions seems 
to have been to capture social aspects of organizations; however, Gaia falters in important details. 
As stated above, permissions and responsibilities in Gaia are not interagent relationships. For ex- 
ample, the REVIEWER has the permissions read Papers and change ReviewForms. But this seems 
to assume a computational intermediary (left unspecified in Gaia) with resources (the papers) 
where these activities must be performed. (In lOSE, cliange reviewForms would be modeled as a 
communication from the REVIEWER to the PROGRAM CHAIR or the overseeing PC MEMBER and 
its body would contain the updated review.) Responsibilities specify what an agent adopting the 
role ought to do but again this seems to assume an unspecified entity to whom the agent would 
be responsible. 



A:16 



Chopra and Singh 



— Solely Social Meaning: Violated. As we noted above, Gaia does not have any true social ab- 
stractions. 

— Separating Social from Technical: Partially fulfilled. Gaia aspires to social-level modeling by 
modeling systems as organizations and having agents adopt roles in organizations. Gaia, to its 
credit, distinguishes between open systems and closed systems. It explicitly mentions that agents 
could represent different stakeholders. However, unlike a principal in lOSE, an agent in Gaia is 
anything that has its own thread of control. Specifically, even in open systems, "active" compo- 
nents such as active databases, are modeled as agents. 

— No Principal Internals: Violated. Gaia makes internal agent behavior (e.g., ReviewPaper) explicit 
by placing activities in role specifications, thereby exposing an agent's internal decision-making. 
(ReviewPaper would not appear in an lOSE protocol because it does not involve communication — 
it is an internal activity.) 

In summary, Gaia aspires to modeling open systems via roles and protocols, but falters in im- 
portant details. Although it is not explicitly machine-oriented, it betrays a conceptually centralized 
mindset. As such, it is not adequate for the modeling of open sociotechnical systems. 

6.4. Choreographies in Service-Oriented Computing 

A choreography specifies the schemas of the messages exchanged as well as constraints on their or- 
dering and occurrence. A choreography is conceptually decentralized and involves roles that princi- 
pals may potentially adopt. Interestingly, choreographies fit in the paradigm of Figure|5a] Principals 
adopting roles in a choreography would potentially maintain their own ledgers and interact via a 
digital messaging system that carries their messages to each other However, there is no computa- 
tional support for the social state: choreographies do not specify the social meanings of messages 
and as a result do not capture the social expectations interacting principals may have of each other 
Choreography description languages, e.g., WS-CDL |WS-CDL 2005|, support specifying the in- 
ternal activities of principals in the choreography itself. For instance, the WS-CDL notion of worku- 
nits may be used to specify conditional actions by a principal. Likewise, Mendling and Hafner 
120081 use workunits to specify the internal compliance checks that a tax adviser would make in 
handling a client's annual statement (p. 532), thereby violating encapsulation. 

— Accountability Modularity: Partially fulfilled. Choreographies support compliance at the techni- 
cal level: principals must send messages in the prescribed order, otherwise they are not compliant 
with the choreography. However, lacking representation of social meaning and social state, a vi- 
olation of a choreography does not necessarily amount to a violation at the social level. 

— Explicit Social Meaning: Violated. Lack a representation of social meaning. 

— Solely Social Meaning: Violated. Follows from the lack of a representation of social meaning. 

— Separating Social from Technical: Fulfilled. Choreographies specify interactions with reference 
to roles that principals may adopt. 

— No Principal Internals: Partially fulfilled. In principle, choreographies seek to specify interac- 
tions; however, in practice, they also specify the internal activities of principals. 

Choreographies seek to model interactions; however, they do so in terms of low-level control and 
data flow abstractions and often specify aspects of principals' internal behavior. Therefore, they also 
do not fare well with respect to the lOSE principles. 

6.5. Summary of Evaluation 

Table II V I contrasts traditional approaches with commitment protocols, explained in Section|5]as an 
exemplar of lOSE. i*, Tropos, and KAOS are all machine-oriented since their primary specification 
artifact is that of a machine (the system actor in i* and Tropos and a collection of agents in KAOS) 
that would meet stakeholder requirements. Nonetheless, i* and Tropos perform better than KAOS 
in our evaluation because unlike KAOS, they model stakeholders and their relations explicitly. 
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Principle 


1* & Tropos 


KAOS 


Gala 


Choreographies 


Commitments 


Accountability modularity 


X 


X 


X 




/ 


Explicit social meaning 




X 




X 


/ 


Solely social meaning 




X 


X 


X 


/ 


Separating social from technical 




X 




/ 


/ 


No principal internals 


X 


X 


X 




/ 



7. RELEVANT LITERATURE 

In the foregoing, we have extensively discussed the literature most pertinent to our claims. Here, we 
discuss other relevant literature. 

Commitments. Commitments are recognized in the literature as a key social abstraction. Singh 
|jj998| introduced social commitments as a way of formalizing agent communication that was 
suited to open systems. Fornara and Colombetti 1200211 gave an operational semantics for com- 
mitments. Yolum and Singh 1 2002] specified commitment protocols in the event calculus. Newer 
work has tended more toward SE themes: methodologies for composing commitment protocols 
BDesai et al. 2010L patterns [Singh etal. 2009 Chopra and Singh 201 1], the relationship of com- 



mitments with the notion of goals in Tropos [ [Chopra et al. 2010a|, and monitoring requirements via 
commitments ORobinson and Purao 200911 . Young and Anton [[20101 apply commitments to identify 
software requirements from regulatory policies and Paja et al. |2012| to extract security require- 
ments for organizations. Baldoni et al. [[20121 present commitment protocols that support temporal 
properties. 

The value we add to this body of work is making explicit connections between the ontology and 
principles implicit in commitment-based approaches with those implicit in traditional SE. lOSE, as 
a new paradigm for the sociotechnical systems, provides a natural home for commitments. 

Agent-Oriented Software Engineering Despite the apparent similarity between the notion of 
agents and principals and talk of interaction in many AOSE methodologies, they (as exemplified 
by Gaia and Tropos) violate key lOSE principles. Some AOSE approaches are logically centralized, 
e.g., geared toward efficient problem-solving. Gaia and other AOSE methodologies acknowledge 
the distinction between open and closed systems and emphasize interactions. They correctly clas- 
sify problem solving systems that distribute a problem across agents as closed. 

However, AOSE methodologies betray, if not centralized mindsets, at least considerable concep- 
tual difficulties. Vasquez-Salceda et al. [2005] model the objectives of social systems as goals and 
the systems as controllers (p. 338): "Facilitation roles are usually provided by agents controlled by 
the society, and follow a trivial contract." But in a sociotechnical system, there is no unitary mul- 
tiagent system or society that controls resources. And an organization has no goals that overarch 
the goals of other participants — that is, an organization would be one of many participants in a so- 
ciotechnical system. Van Riemsdijk et al. [2009 1 too are motivated by the modeling of open systems 
but conceptualize a multiagent system as having collective goals. 

Wagner's [[20031 Agent-Object-Relationship (AOR) ontology proposes two kinds of models to 
support the design of a multiagent system: external (observer's perspective, including interaction 
models) and internal (agent's perspective). Newer work by Guizzardi et al. [2010| is based on the 
AOR ontology. Wagner's internal-external distinction aligns well with lOSE. Unfortunately, AOR 
subverts the internal-external distinction by including in external models aspects of the internal or- 
ganization of agents, such as their beliefs (in agent diagrams) as well as reactive rules that specify 
how an agent would respond to events. Singh fl99r| introduced social commitment as a concept dis- 
tinct from the mentalist concept of internal commitment [Cohen and Levesque 1990 |. AOR, Tropos, 
and i* employ internal commitments. 

SeiTano and Leite [201 1] map i* concepts to agent programming concepts such as beliefs, desires, 
and intentions. They map dependencies between two agents to the joint desires of those agents. Us- 
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ing their methodology, one specifies the internals of one or more agents. Thus even though Serrano 
and Leite don't involve an explicit system actor, the approach is conceptually centralized. 

How can we reconcile the facts that many AOSE methodologies are conceptually centralized yet 
model interactions? AOSE methodologies yield physically distributed systems of agents that pursue 
centrally assigned goals. Interactions in AOSE are focused on the technical means to achieve such 
goals whereas interactions in lOSE have social standing. 



Information Systems Modeling McCarthy pi982| proposed REA as a generahzed model for ac- 
counting that is based on resources, events, and agents and relations among them. REA is finding 
applications in services and information systems modeling, e.g., | |Weigand et al. 20rT| . REA seeks 
to capture the fundamental economic model underlying accounting. Our endeavor is analogous: to 
develop a general model of sociotechnical systems, based on social abstractions. The key distinc- 
tion between lOSE and REA is that REA models ultimately represent an organization's internal 
perspective, not its interactions with others. This is evident from REA's inside-outside distinction. 
One of REA's accountability relations identifies the responsible agent for an event inside an orga- 
nization; another is between an outside agent and an event. lOSE commitments are more general: 
each commitment identifies the accountable party and the party to whom it is accountable for what. 

The second distinction stems from the duality of events and the corresponding reciprocity of 
commitments — ^reflecting the roots of REA in accounting. Duality in REA relates two events that 
together characterize the give-and-take of an economic exchange (e.g., pay and deliver). These events 
execute (i.e., fulfill) the corresponding reciprocal commitments. lOSE does not give any special 
place to either duality or reciprocity. No lOSE commitment is necessarily reciprocal: If x is com- 
mitted to y, there is no requirement that y be committed to x (though it is allowed). 

Gordijn and Akkermans |2001| propose the e'^-value ontology and associated methodology in 
order to specify and analyze so-called business models to evaluate their profitability for all stake- 
holders involved. A business model represents stakeholders as actors (e.g., customer). Other impor- 
tant concepts are value objects (e.g, online articles), and value exchanges among actors (e.g., with 
an article provider for articles and their payment). Commitment protocols could be used to cap- 
ture the notion of value exchange among actors; further commitment protocols could be analyzed 
for feasibility BDesai et al. 20081 . However, unlike commitment protocols and in violation of lOSE 
principles, e^-value models also depict the internal flow of values in Petri Net-like notation. 



Human-Computer Interaction (HCI) Following developments in HCI, the term "social" is often 
associated in RE with the interplay between social factors and the design of technical artifacts 
(as in the design of work, e.g., see |Flores et al. 1988 1), especially as concerns user interface and 
experience (e.g., see llSutcliffe et al. 201 111 ). The lOSE treatment of "social" is more general and 
includes not just people but entities such as enterprises and organizations that may be conceptuahzed 
as social actors — which enables lOSE to tackle sociotechnical systems as we define them. 



Compliance Compliance with service-level agreements, regulations, and business contracts is gain- 
ing interest in software engineering. Organizations are increasingly concerned with the question of 
compliance with regulatory frameworks such as HIPAA | Young and Anton 2010) and Sarbanes- 
Oxley. The challenges here are threefold: one, how to model regulations; two, how to determine 
the compliance of a principal's behavior with regulations; and, three, how to design a principal's 
information systems such that it is (likely to be) compliant with the regulations. Siena et al. 120 101 
develop a Tropos-inspired modeling language to capture and reason about such regulations. lOSE 
can potentially support a more flexible notion of compliance geared toward open systems. 

Although high-level concepts such as obligations, permissions, and so on are often employed in 
software engineering, they are used to capture behavioral constraints abstractly but are not grounded 
in communication as commitments are. A more detailed discussion is out of the scope of this paper 
but interested readers are referred to jSingh 2012) for an in-depth discussion. 
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8. DISCUSSION AND FUTURE WORK 

Our work began from the recognition that open sociotechnical systems are conceptually decentral- 
ized and their principals are autonomous social entities. Specifying a sociotechnical system amounts 
to specifying a protocol, i.e., a specification of the interactions among its potential participants. We 
showed that existing approaches take a fundamentally centralized view of sociotechnical systems 
design: they are geared toward the specification of a machine, not a protocol. 

We presented lOSE as a new approach for the engineering of sociotechnical systems. lOSE is 
driven by key technical demands: autonomy, accountability, and loose coupling. To illustrate lOSE, 
we introduced protocols in which the meanings of the messages are specified in terms of commit- 
ments as a natural way to address these technical demands. We formulated the lOSE principles 
inspired by, but distinct from, the traditional SE principles. We undertook a detailed analysis of 
some leading relevant SE approaches to show which lOSE principles they violate. Traditional SE 
falls short not because the abstractions it employs are low level, but because they deemphasize inter- 
action. To support this claim, we consider well-known requirements modeling approaches, which 
emphasize high-level abstractions such as goals and dependencies | Mylopoulos et al. 1999| but do 
not accord first-class status to interactions. 

Even in the simple appointment scheduling setting, the benefits of lOSE are obvious: what was 
previously seen as the problem of specifying a meeting scheduler, under lOSE turns into two inde- 
pendent problems of (1) specifying the meeting scheduling protocol, and (2) specifying principals 
to participate in the protocol. This reflects Parnas' conception of modularity as the division of labor. 

Our evaluation of the traditional approaches is not a blanket criticism but rather a critical exami- 
nation that highlights the differences in their assumptions from the principles of lOSE. Further, our 
evaluation was limited to the system models or specifications that existing approaches advocate. 
We did not, for instance, dwell upon the modeling of functional versus nonfunctional requirements 
or the elicitation of requirements from stakeholders, areas in which current sociotechnical systems 
approaches (including i*, Tropos, and KAOS) have made substantial progress. 

Although we carefully differentiate lOSE from traditional SE, the two complement each other. 
lOSE deals with systems (viewed as protocols) whereas traditional RE deals with components or 
principals' behaviors (viewed as machines). The former is typified by commitments and other so- 
cial constructs; the latter by goals and other mental constructs. Recent works | |Chopra et al. 2010b 



Telang et al. 2012 1 have begun to relate these views from the standpoint of building agents who 
can function effectively in sociotechnical systems characterized by commitments. We have re- 



cently I Chopra et al. 2010a Telang and Singh 2009|, sought to apply Tropos-like models towards 



the specification of sociotechnical systems. These works replace intentional dependencies with com- 
mitments and do not consider a system actor. Further, each actor is understood as a role, i.e., inert 
and lacking any goals. Goals are applied in the modeling the principals who may potentially adopt 
roles in the sociotechnical system. 

We defer the task of systematically laying out the methodological elements of lOSE, as they 
overlay the main concepts and principles we introduced above. We expect to go beyond methodolo- 
gies for specifying and composing protocols, e.g., IDesai et al. 20 101, by incorporating the key RE 
considerations of stakeholders and requirements. The nature of requirements for protocols appears 
quite different from requirements for machines. For example, a requirement such as "a meeting is 
scheduled within three hours of the request" makes sense for a machine but not a protocol — though 
it could be negotiated between the principals playing the MI and MP roles. A requirement that "a 
principal can observe whether another principal is complying with some commitment" makes sense 
for a protocol but less so for a machine. The bases from which to engineer protocols is a timely and 
pertinent direction of research. We imagine that existing RE methodologies would provide a useful 
starting point for investigations into a methodology for lOSE. 
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